Authenticating connections and program identity in a messaging system

ABSTRACT

A messaging system enables client applications to send and receive messages. The messaging system includes independent component programs performing different functions of the messaging system, such as connection managers that maintain network connections with the client applications, a message router that sends received messages to recipient applications through network connections, and a dispatcher that authenticates other component programs. A messaging server may authenticate client applications using certificate-based authentication (e.g., private and public keys), authentication transfer from another trusted messaging server, or other methods (e.g., user name and password). To authenticate a component program, the dispatcher compares instantiation information (e.g., user identity, process identifier, creation time) of the component program provided by the operating system with instantiation information saved in a shared memory at the time of the component program&#39;s instantiation. In response to a match, the dispatcher provides the component program with secure information through an inter-process communication socket.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a divisional application of U.S. Ser. No.15/011,334, filed Jan. 29, 2016, which claims the benefit of U.S.Provisional Patent Application No. 62/109,512, filed Jan. 29, 2015,which is incorporated by reference herein in its entirety.

BACKGROUND

The present disclosure generally relates to a messaging-orientedmiddleware system and, more particularly, to establishing a chain oftrust for secure connections between component programs of the messagingsystem and a client application.

Messaging-oriented middleware systems (also referred to herein as“messaging systems”) facilitate communication between clientapplications distributed across diverse operating environments. Forexample, a messaging system enables communication between clientapplications executed by different servers with different operatingsystems. The messaging system includes different component programs on amessaging server as well as a client device. Establishing a chain oftrust between these programs is difficult because many of these programsare started automatically without direct intervention by a user. When auser starts a program, the user may establish a chain of trust using auser name and password that can be verified through a system such aslightweight directory access protocol (LDAP). However, programs startedautomatically cannot request a password from a user. This problem occursboth when a client device establishes a connection with the messagingsystem and when the messaging system instantiates a component program.Overall, password-based systems are inadequate for authenticatingautomatically initiated programs in a messaging-oriented middlewaresystem.

SUMMARY

A messaging system enables client applications to send and receivemessages in a format independent of the client applications' respectiveoperating environments. The messaging system includes independentcomponent programs performing different functions of the messagingsystem to improve messaging system reliability and flexibility. Theindependent component programs of the messaging server includepersistent connection managers that maintain connections with the clientapplications as well as an easily updateable message router that directsreceived messages to recipient applications through correspondingnetwork connections. The component programs may also include an easilyupdateable dispatcher that establishes connections, authenticates clientapplications and the component programs of other messaging servers, andmanages the connection managers.

According to one aspect, the messaging system ensures authentication ofcomponent programs by performing the following steps. The dispatcherstores a private key in a memory accessible by a root user identity andcreates an inter-process communication (IPC) socket connection with acomponent program that is either a message router or a connectionmanager. The component program does not have permission to access thememory storing the private key. The dispatcher determines that thecomponent program is running. In response to the component programconnecting to the IPC socket connection, the dispatcher (a) obtains afirst set of instantiation information describing the component programfrom shared memory; (b) obtains a second set of instantiationinformation from an operating system regarding the component program;(c) compares the first instantiation information to the secondinstantiation information; and (d) sends the component program theprivate key through the IPC socket connection if the first instantiationinformation matches the second instantiation information.

According to another aspect, a messaging system authenticates networkconnections between a remote program and a messaging server byperforming the following steps. The connection manager receives, at oneof its ports, a network connection transferred from the dispatcher. Themessage router sends (through the connection manager) a challenge stringcontaining data unique to the network connection. The message routerreceives (through the connection manager) a challenge string responsefrom the remote program. The challenge string response includes asignature on the challenge string from with a private key paired with anapproved public key. The message router verifies whether the receivedchallenge string response is valid for the network connection. Inresponse to determining that the received challenge string response isvalid, the message router processes messages sent through the networkconnection. In response to determining that the received challengestring response is invalid, the message router instructs the connectionmanager to disconnect from the client application by closing the networkconnection.

According to another aspect, the messaging system performsauthentication transfer for a client application having an authenticatednetwork connection with a first messaging server in a first messagingenvironment to enable the client application to login to a secondmessaging server in a different messaging environment by performing thefollowing steps. The second messaging server receives a request from theclient application to initiate a connection and sends a challenge stringto the client application. The second messaging server receives a loginrequest from the client application, which includes the clientapplication's user identity and incorporates the second messagingserver's challenge string, as encrypted by the first messaging serverusing the first messaging server's signature. The second messagingserver decrypts the data in the login request and verifies theauthentication credential included in the login request by verifyingthat the challenge string matches the originally sent challenge string.If the authentication credential is valid, the second messaging serververifies the user identity and messaging environment metadata includedin the login request. If the authentication credential, user identity,and messaging environment metadata are valid, the second messagingserver processes messages received from the client application.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. (FIG. 1 is a block diagram of a system environment including amessaging system and client devices, in accordance with an embodiment.

FIG. 2 is a block diagram illustrating modules within a client deviceand messaging server, in accordance with an embodiment.

FIG. 3 is an interaction diagram illustrating a client applicationestablishing a connection with the messaging system, in accordance withan embodiment.

FIG. 4 is an interaction diagram illustrating a client applicationsending and delivering a message to the messaging system, in accordancewith an embodiment.

FIG. 5 is an interaction diagram illustrating an example process ofauthenticating a network connection, in accordance with an embodiment.

FIG. 6 is an interaction diagram illustrating an example process oftransferring authentication for a client device between messagingservers, in accordance with an embodiment.

FIG. 7 is an interaction diagram illustrating an example process ofauthenticating identity of a component program, in accordance with anembodiment.

DETAILED DESCRIPTION

The Figures (FIGS.) and the following description describe certainembodiments by way of illustration only. One skilled in the art willreadily recognize from the following description that alternativeembodiments of the structures and methods illustrated herein may beemployed without departing from the principles described herein.Reference will now be made in detail to several embodiments, examples ofwhich are illustrated in the accompanying figures. It is noted thatwherever practicable similar or like reference numbers may be used inthe figures and may indicate similar or like functionality.

Figure (FIG.) 1 is a block diagram of a system environment includingmessaging system and client devices 110A and 110B (generally, clientdevices 110), in accordance with an embodiment. The messaging systemincludes messaging servers 120A and 120B (generally, messaging servers120), which are communicatively coupled to each other and to clientdevices 110A and 110B through the network 130 (which may include a cloudof messaging servers 120).

The client devices 110 are computing devices including both user devicesand servers. User devices include applications to enable users to view,input, manipulate, and modify information, which may be stored locallyor retrieved from another device. Example user devices include desktopcomputers, laptop computers, servers, smartphones, tablet computers, orany other type of network-enabled device. Servers include databases thatstore information or programs that generate, modify, and deleteinformation, both automatically and in response to commands from userdevices and other servers. Example servers include rack-mounted serverswith a Unix-based operating system. Some client devices 110 havecharacteristics of both user devices and servers.

The messaging system facilitates communication between clientapplications executed by client devices 110 by providingmessaging-oriented middleware functionality. A client applicationcommunicates with at least one other client application through messagespassed by the messaging system. In a typical use case referred toherein, client device 110A executes a client application thatcommunicates with another client application executed by client device110B through the messaging system. However, different clientapplications executed by the same client device 110 may communicatethrough the messaging system, and different instances of the same clientapplication may communicate through the messaging system.

The messaging system includes one or more messaging servers 120 (e.g.,messaging servers 120A and 120B), which are co-located with clientdevices 110, remotely located from client devices 110 (e.g., in a datacenter), or geographically dispersed (e.g., in a plurality of datacenters, virtual machines, or cloud computing environments). Using aplurality of messaging servers 120 beneficially improves reliability andscalability of the messaging system. For example, the messaging systemmay include resiliency functions that identify when a messaging server120 has failed and distribute the functionality of the messaging server120 to other active messaging servers 120 or to a backup messagingserver 120. Furthermore, the messaging system uses load balancing todistribute messages between similar client applications to improveresponsiveness.

As used herein, a “message” refers to any communication between clientapplications. Example messages include a request for information from aclient application, a response including the requested information,unrequested information (e.g., an update, a status report), a commandfor a client application, and a confirmation indicating a result of thecommand. The message may include encoded information representing text,numerical data, structured data (e.g., a database table), audio data,image data, video data, programmatic commands, or a combination thereof.The message may further include a header with routing information usedto identify message recipients or topics that recipients are registeredto receive.

The messaging system sends and receives messages through connectionswith client applications, which are typically persistent connectionsprovided by a protocol with guaranteed transmission (e.g., TransmissionControl Protocol (TCP), Stream TCP). Using a guaranteed-deliveryprotocol beneficially improves reliability of the messaging system andsimplifies development of client applications that interface with themessaging system. In general, the messaging system receives a message,stores the message, identifies one or more client applications toreceive the message, and sends the message to the identified clientapplications. Typically, the messaging system retains the message instorage only until the messaging system verifies delivery of the messageto the identified client applications.

The messaging system supports one or more messaging modes, whichindicate the number of message recipients and whether a response isexpected. The messaging modes include broadcast mode, load balancedrequest/response (semaphore) mode, session (continuous semaphore) mode,fanout request mode, inter-process communication (IPC) mode, or acombination thereof.

In broadcast mode, a client application sends a message to one or moreclient applications without expecting a response. The broadcast messageindicates a topic to which the client application is publishing themessage. The messaging system delivers the broadcast message to clientapplications subscribed to the topic. A client application may bothpublish and subscribe to a topic, and multiple client applications maypublish to a topic. If no client application is subscribed to the topic,then the messaging system does not deliver the broadcast message to anyclient application. To reply to a broadcast message, a clientapplication may publish a broadcast message to a topic to which thepublishing client application is subscribed or may use a differentmessaging mode.

In semaphore mode, a client application sends a single request to aspecified client application and expects one or more response messagesfrom the other client application. In continuous semaphore mode, aclient application sends multiple request messages to a specified clientapplication and expects one or more responses from the other clientapplication. In a fanout request mode, a client application sendsrequest messages to all client applications listening on a particulartopic and expects to receive response messages from all of them. Forexample, a request mode message is sent to all client applications of aparticular program type, belonging to a particular organization, orboth. In IPC mode, two client applications exchange messages. Forexample, two client applications on the same client device 110 mayexchange messages in IPC mode to facilitate remote method calls orexecution or communication between two different operating environments.

The client devices 110 and the messaging servers 120 are connected via anetwork 130, which may be any suitable communications network for datatransmission. The network 130 uses standard communications technologiesand/or protocols and can include wide-area networks (e.g., theInternet), local-area networks (e.g., an organization's intranet), orboth. In another embodiment, the network 130 includes custom and/ordedicated data communications technologies.

Typically, both client devices 110 and messaging servers 120 includehardware and software to connect to network 130 (e.g., via Ethernet,Wi-Fi, or other telecommunication technologies), store information(e.g., volatile-memory, non-volatile memory, another computer-readablemedium), and process information (e.g., a processor). A client device110 or messaging server 120 may optionally include hardware and softwareto present information (e.g., a display device, a projector, an audiospeaker), to receive user commands and other user inputs (e.g., an inputperipheral, a microphone, a camera), or both.

Although FIG. 1 illustrates two instances of the client devices 110 andthe messaging servers 120, the system environment may include any numberof these devices. The messaging system may include a single messagingserver 120 or a plurality of messaging servers 120. Where the messagingsystem includes a plurality of messaging servers 120 in a data center,the messaging servers 120 may be hierarchically organized, such as in atree structure with one messaging server 120 serving as a root node forthe data center, or with any other topology. The messaging system may bedistributed across a plurality of data centers. In this case, one ormore messaging servers 120 may serve as global hubs that coordinatecommunication between messaging servers 120 in different data centers.If the messaging servers 120 are organized in a tree hierarchy withinthe data center, the messaging servers 120 serving as root nodes ofrespective data centers may also be child nodes with respect to globalhub nodes.

System Architecture

FIG. 2 is a block diagram illustrating modules within a client device110 and messaging server 120, in accordance with an embodiment. Someembodiments of the client device 110 and messaging server 120 havedifferent or additional modules than the ones described here. Similarly,the functions can be distributed among the modules in a different mannerthan is described here, and the modules of the messaging server 120 maybe executed by multiple messaging servers 120.

The client device includes one or more client applications 205. A clientapplication 205 refers to any application that communicates through themessaging system 120. Example client applications support databasemanagement, person-to-person communication, multimedia streaming,operations management, accounting, regulatory compliance, asset trading,asset monitoring, or any other enterprise or recreational function. Aclient application may include an application programming interface(API) that other programs may use to request information from the clientapplication 205 or to send commands to the client application 205. Aclient application 205 may include a graphical user interface (GUI) fora user to review, provide, and manipulate information.

The client application 205 generates a message for the messaging system,and sends the message to a messaging server 120. From the standpoint ofthe messaging system 120, the message is raw data that is notinterpreted by the messaging system itself. This data could representanything, such as raw text, structured data, a serialized Java object ora structured document in JavaScript Object Notation (JSON) or ExtensibleMarkup Language (XML). To generate a message, the client application 205generates a message body that incorporates the information and a messageheader that identifies a type of the message and any necessary routinginformation. For example, the client application 205 may encode theinformation into a byte format. As part of encoding the information, theclient application 205 may encrypt the information to improve security.As expected, the client application 205 may also receive messages fromthe messaging server 120.

The client application 205 generates a header with parameters mayinclude any information not part of the main body of content of themessage, such as a messaging mode (e.g., broadcast mode, semaphore mode)and one or more topic identifiers corresponding to the messaging mode,or any other necessary routing information. For the broadcast mode, thetopic identifier identifies which recipient client applications 205 aresubscribed. For other messaging modes (e.g., semaphore mode, requestmode, IPC mode), a publish subscribe model or a direct addressing modelmay be used such that a set of one or more receiving applications 205use a semaphore register for a topic identifier.

The messaging server 120 is comprised of three separate programs modulesincluding a dispatcher 220, one or more connection managers 230, amessage router 240, and a state store 250.

The client application 205 is communicatively coupled to the dispatcher220 and connection manager 230 by network connections 215 and 217,respectively. The client application 205 is not necessarilysimultaneously coupled to the dispatcher 220 and connection manager 230by network connection 215 and 217, however. For example, the clientapplication 205 establishes network connection 215 with the dispatcher220, which transfers the network connection 215 to the connectionmanager 230, thereby establishing network connection 217. The networkconnections 215 and 217 are generally transport-layer networkconnections implemented using connection oriented communicationsprotocol having a guaranteed transmission mechanism (e.g., TCP, streamTCP). However, the transport-layer network connections 215 and 217 maybe replaced or supplemented by another connection oriented networkcommunication mechanism.

The dispatcher 220 is communicatively coupled to the connection manager230 using IPC socket connections 225. The IPC socket connections 225enables ordered reliable sending of datagrams, stream, and filedescriptors between processes in the operating system kernel, so the IPCsocket connections 225 may be used to pass network connections (e.g.,215 and 217) between program modules (e.g., 220 and 230) executed withinthe same operating environment. For example, the IPC socket connections225 may be a Unix domain socket. The dispatcher 220 is similarly coupledto the message router 240 using IPC socket connection 227.

The message router 240 is connected to each connection manager 230through a pair of messaging queues 235, one in each direction. Thesequeues 235 are an IPC mechanism that delivers data objects in the sameorder they were sent. This transmission of data objects is reliable andpersistent. In other words, the messaging queue has a first in, firstout (FIFO) structure. A messaging queue includes internal structure thatseparates discrete data objects placed in the messaging queue 235, whichfacilitates reading of the messaging queue by a recipient componentprogram. One example messaging queue 235 is a Portable Operating SystemInterface (POSIX) messaging queue. Data objects in a messaging queue 235are generally stored in memory allocated to the kernel of an operatingsystem executed by a messaging server 120. Alternatively oradditionally, data objects in a messaging queue 235 are stored in a filesystem or other kernel persistent memory such as state store 250.

The dispatcher 220, the connection manager 230, and the message router240 may access, write, modify, and delete data in the shared memory 250through memory connections 223, 233, and 243, respectively. The sharedmemory 250 may be memory mapped location accessible by the programmodules or a subset thereof. Accordingly, different program modules mayshare the same objects in memory, facilitating inter-processcommunication between the program modules. As an example, the memoryconnections 223, 233, and 243 access POSIX memory mapped files. However,a given program component cannot necessarily access all memory locationsin the shared memory 250. Instead, some memory locations are accessibleonly to a subset of the component programs, as described in furtherdetail below.

The dispatcher 220 establishes network connection 215 with a clientapplication 205 in response to receiving a connection request from theclient application 205.

Having established the network connection 215, the dispatcher 220selects a connection manager 230 and transfers the network connection215 to the selected connection manager 230. The dispatcher 220 selects aconnection manager 230 according to a load balancing mechanism. Avariety of load balancing mechanisms are possible. For example, thedispatcher 220 may load balance by determining a utilization rate amongconnection managers 230 accessible by the dispatcher 220. For example,the utilization rate may refer to a number of the connection manager'snetwork connections. After selecting a connection manager 230, thedispatcher 220 transfers the connection 215 to it through the IPC socketconnection 225. As part of transferring a network connection, thedispatcher 220 stores a connection state in state store 250. Theconnection state describes the network connection 215 and associates thenetwork connection with the selected connection manager 230.Establishing a connection 217 is described in further detail withrespect to FIG. 3.

The connection manager 230 maintains network connections transferredfrom the dispatcher 220. The connection manager 230 sends and receivesmessages through network connection 217. The connection manager 230stores received messages by storing the message body, the messageheader, or both in state store 250. The connection manager 230 notifiesmessage router 240 of the received message by forwarding a reference tothe message to messaging queue 235. For example, the connection manager230 generates a handle to identify the message. The handle maycorrespond to the storage address of the message in the state store 250.The connection manager 230 transfers the handle, the message header, orboth to the message router 240 through the messaging queue 235.

Additionally, connection managers 230 process (e.g., assemble, send,delete) messages in response to message routing instructions receivedfrom the message router 240 through the messaging queue 235. Forexample, a message routing instruction to send a message includes amessage header and a message handle. The connection manager 230 accessesthe message body corresponding to the message handle from the queue 235,assembles a message including the message body and the message header,and sends the message to one or more recipient client applications basedon the topic identified by the message header. For example, theconnection manager 230 sends the message through network connection 217to the client application 205 on the client device 110.

Because a message may be sent to multiple recipients, multipleconnection managers 230 may share access to the message in the sharedmemory 250. To ensure that a message is retained until it has been sentto all intended recipients, the connection manager 230 may access andupdate a completion state associated with the message in the sharedmemory 250. The completions state indicates completion of routinginstructions related to a message. For example, in response to a routinginstruction to send a message, the connection manager 230 updates thecompletion state to reflect completion of the routing instruction. Inresponse to a routing instruction to delete a message, a connectionmanager 230 compares the completion state with a completion conditionincluded in the routing instruction to delete the message. If thecompletion state fulfills the completion condition, the connectionmanager 230 deletes the message. If the completion state does notfulfill the completion condition, the connection manager will simplyleave the message as is, as it is presumed that another connectionmanager still needs to act on a routing instruction with the message inorder to fulfill the completion condition.

The message router 240 receives a reference to a received message from aconnection manager 230 and generates routing instructions for one ormore connection managers 230 to deliver the message. The reference tothe received message may include a message handle, a message header, orboth. The message router 240 determines one or more topic identifiers ofthe message based on the message header. For example, for a broadcastmessage, the message router 240 determines recipient client applications205 that are subscribed to a topic indicated by a topic identifier inthe message header. The message router 240 then determines the networkconnections 217 corresponding to the recipient client applications 205,and determines the connection managers corresponding to the determinednetworked connections 217. The message router 240 sends those connectionmanagers 230 routing instructions to send the message to the recipientclient applications 205 using the determined connections 217. Therouting instructions include a message handle as well as a messageheader that may include the topic identifier and in some instances themessaging mode as well. The routing instruction is delivered over themessaging queue 235 to a particular connection manager 230 in the sameorder they were sent by the message router 240 to ensure predictablebehavior. For example, ensuring in-order delivery of instructions to aconnection manager 230 ensures that the recipient client application 205receives the messages in the same order they were sent by the senderclient application 205.

The message router 240 maintains a routing state that is associated witha message in state store 250. The routing state of a message correspondsto the routing instructions issued to connection managers 230. Forexample, as part of issuing a routing instruction, the message router240 updates the message's routing state to reflect that the routinginstruction has been sent to the connection manager 230. When themessage router 240 sends a last routing instruction pertaining to amessage handle, the message router 240 determines a completion conditionand attaches the completion condition to the last routing instruction.In one embodiment, the completion condition is the touch count. The lastrouting instruction may either be the last substantive action to betaken with respect to the message, or it may be an additional routinginstruction sent after the routing instruction handling the lastsubstantive action to explicitly request deletion of the messageidentified by the message handle when an included completion conditionis fulfilled. Using the completion condition, the connection managers230 tasked with fulfilling the last routing instruction canindependently verify whether the message is ready for deletion.

The state store 250 maintains state information accessible to at least asubset of the component programs 220, 230, and 240 and maintained by thecomponent programs, as described above. The state information includesmessage bodies, message headers, a completion state, a routing state,and a connection state. In some embodiments, the state store 250 issegmented so that different modules may access and modify only a subsetof the state information.

The state store 250 may contain message payloads accessible to theconnection managers 230, and message headers accessible to the messagerouter 240. Additionally, the connection managers 230 and message router240 pass message headers between them through messaging queue 235. Thestate store 250 further contains a table of connection states describingthe network connections 215 and 217. The connection states areaccessible by the connection managers 230, the dispatcher 220, or both.For example, the table entry for a network connection 217 may includeany one or more of a socket used by the corresponding connection manager230, an assigned UID of the socket or corresponding client application205, and authentication information.

The state store 250 is hosted on memory allocated independently from thedispatcher 220, and message router 240, so a planned restart and/orupdate to any of these programs will not result in the loss of the stateinformation.

Updates to the dispatcher 220 may result in delays to establishing newconnections, but the connection manager 230 may maintain existingconnections while the dispatcher 220 is updated. Similarly, updates tothe message router 240 may delay routing of received messages, but thestate store 250 that contains the received messages, routing state, andcompletion state is not affected by changes to the message router 240.

Establishing a Connection with a Client Application

FIG. 3 is an interaction diagram illustrating a client applicationestablishing a connection with the messaging system, in accordance withan embodiment. The client device 110A (e.g., client application 205)initiates 310 network connection 215 with the dispatcher 220. The clientdevice 110A initiates 310 the connection by contacting the dispatcher220 at a socket and waits for establishment of the network connection215. The dispatcher 220 accepts the network connection 215 andacknowledges the establishment of network connection 215 to the clientdevice 110A.

The dispatcher 220 selects 320 a connection manager 230. As describedpreviously, the dispatcher 220 selects 320 the connection manager 230 toensure load balancing among connection managers 230. The dispatcher 220transfers 330 the connection to the selected connection manager 230. Totransfer the connection the dispatcher 220 generates a UID for thenetwork connection 215 and identifies host information of the clientapplication 205 and/or the client device 110A. The dispatcher 220 sendsthe UID for the network connection and the host information through IPCsocket connection 225. The host information may include a socketassigned to the client device 110A or the client application 205, orsome other signifier of where the connection is to route messages sothat they arrive at the client application 205.

The connection manager 230 requests 340 a session from the messagerouter 240. For example, the connection manager 230 may request 340 thesession by sending a data object including the host information (or theUID) to message router 240 through messaging queue 235. The messagerouter 240 establishes 350 a session based on any received information.For example, establishing a session may include the message router 240generating a confirmation message and storing the confirmation messagein the state store 250. The confirmation message may include thereceived information. The message router 240 instructs 360 theconnection manager 230 to send the confirmation message to the clientdevice 110A. For example, the message router 340 generates and sends arouting instruction to the connection manager 230 through messagingqueue 235. In response to the routing instruction, the connectionmanager 230 establishes network connection 217 and sends theconfirmation message to the client device 110A through the networkconnection 217. Network connection 217 is established at a differentsocket from the socket used by the dispatcher 220 to accept networkconnection 215.

The client device 110A (e.g., client application 205) accepts thenetwork connection 217. The client device 110A also sends 380 a responsemessage to the connection manager 230 through network connection 217.The response message includes information identifying the clientapplication 205, such as a program type of the client application 205and instance name of the client application 205. The connection manager230 stores the response message in the state store 250 and forwards 390the reference to the response message to the message router 240. Usingthe response message, the message router 240 infers that networkconnection 217 is active and stores the connection in association withthe data object (e.g., UID, host information) used to generate theconnection in the state store 250. Subsequently, the message router 240instructs 235 the connection manager 230 to route a message to clientapplication 205 over network connection 217.

In response to a loss of network connection 217, the client application205 may attempt to re-establish a connection by initiating networkconnection 215 with the dispatcher 220. In response to a loss of networkconnection 217, the connection manager 230 sends a data object to themessage router 240 indicating the UID of the lost network connection217. The message router 240 removes the session state it is maintainingin state store 250, and subsequently does not issue instructions for theconnection manager 230 to route any more messages through the lostnetwork connection 217.

Sending a Message Between Client Applications

FIG. 4 is an interaction diagram illustrating a client application 205sending a message to the messaging system, and the messaging systemdelivering the message, in accordance with an embodiment. In someembodiments, the method may include different and/or additional stepsthan those described in conjunction with FIG. 4. Additionally, in someembodiments, the method may perform the steps in different orders thanthe order described in conjunction with FIG. 4, such as performing stepsin parallel.

The client device 110A (e.g., client application 205) sends 405 amessage through network connection 217. In response to receiving themessage, connection manager 230A stores the message in state store 250and generates 410 a message handle. For example, the message handleidentifies the message's storage location in the state store 250. Theconnection manager 230A forwards 420 the message to the message router240. To forward the message, the connection manager 230 forwards themessage handle and message header to the message router 240.

The message router 240 determines 430 routing instructions forconnection managers 230, including a routing instruction for connectionmanager 230B. The message router 240 determines 430 routing instructionsby determining one or more recipient client applications 205 from themessage header. For example, the message router 240 determines arecipient client application from the messaging mode and the one or moretopic identifiers. The message router 240 identifies client applications205 subscribed to the topic corresponding to the topic identifierincluded in the message header. For each identified client application205, the message router 240 generates a routing instruction includingthe message handle and recipient handle. The message router 240 maygenerate other routing instructions, such as a routing instruction todelete a message once the message is sent to all its recipient clientapplications 205.

The message router 240 sends 440 routing instructions to the connectionmanager 230B through messaging queue 235. To send 440 a routinginstruction, the message router 240 accesses a mapping between topicidentifiers and established sessions in state store 250 to identify theappropriate connection manager 230 that can service client applications205 through corresponding network connections 217 by accessing a mappingbetween topic identifiers and the network connections 217.

Messaging System Security

The messaging system 120 may further include computer code toauthenticate network connections from remote programs. Remote programsinclude individual client applications 205 on a client device 110,individual client applications 205 on the same host as the messagingserver 120, and as well as another instance of the messaging server 120.Authentication refers to verifying that a remote program is associatedwith a particular profile having given authorizations in the messagingsystem. In the context of a client application 205, the profile may, forexample, grant authorizations to subscribe to particular topics, topublish messages to particular topics, to send messages (e.g.,responses, requests) to particular client applications 205, or toreceive messages from particular client applications 205. A componentprogram is executed under a particular user identity, which determineswhether a component program has authorization to access particularsegments of the state store 250, to invoke kernel functions of theoperating system (e.g., instantiating an IPC), or to instantiatecomponent programs. For example, only a component program running undera root user identity may access a segment of the state store 250containing secure information (e.g., private keys) or invoke kernelfunctions of the operating system.

A remote program may substantiate its identity through a combination ofone or more authentication mechanisms, including a user name andpassword challenge, process inspection, certificate-basedauthentication, or authentication transfer. A user name and passwordchallenge refers to providing a user name entered through a GUI as wellas a hash of a password entered through the GUI. This authentication isapplicable to client applications 205 directly invoked by a user througha GUI but is inapplicable to automatically started client applications205 as well as component programs of the messaging server 120.

Certificate-based authentication refers to authentication of remoteprograms by exchanging information encrypted using a key.Certificate-based authentication includes asymmetric encryption schemes,where a remote program substantiates its identity by proving that it hasaccess to a private key. For example, a remote program may substantiateits identity by responding to a challenge string sent by the messagerouter 240 with a digital signature that includes a hash encrypted withthe private key of the remote program. Certificate-based authenticationmay alternatively or additionally include symmetric encryption schemes,where the remote program and the dispatcher both have access to a sharedsecret or key, such as a secret generated through a Diffie-Hellman keyexchange. An example of certificate-based authentication is described infurther detail with respect to FIG. 5, described in the section titled“Authenticating Network Connections” below.

Authenticating Network Connections

FIG. 5 is an interaction diagram illustrating an example process ofauthenticating a network connection, in accordance with an embodiment.In the illustrated example, the messaging server 120 authenticates aremote program executed by client device 110 that has establishednetwork connection 217 with a connection manager 230.

The remote program is generally a client application 205 with a networkconnection 217 having been transferred from the dispatcher 220 afterinitiating network connection 215. However, the messaging server 120 mayalso use the process of FIG. 5 to authenticate a component program ofanother messaging server 120 (thus replacing the client device 110 inFIG. 5 and the following description with another messaging server (notshown)). The message router 240 sends 515 a challenge string to theclient device 110 through network connection 217. To send 515 thechallenge string, the message router 240 generates a challenge stringcontaining data unique to the incoming connection, and stores the uniquechallenge string in association with the network connection 217. Togenerate the challenge string, the message router 240 may use anapproved public key (e.g., a root public key) associated with the remoteprogram and accessible to the message router 240. The approved publickey is paired with a root private key accessible to the remote program.

The remote program generates 520 a response to the challenge string. Togenerate 520 the response, the remote program accesses a private keygenerated from the root private key paired with the approved public key.The remote program generates a signature on the challenge string usingthe private key. Generating the signature on the challenge string mayinclude operations such as decoding the challenge string using theprivate key. The remote program sends 525 the dispatcher 220 a responseto the challenge string. The response includes the signature on thechallenge string and a copy of the public key corresponding to theprivate key. For example, the response may be encoded in a format suchas PKCS#7 (Public Key Cryptography Standard #7).

The message router 240 receives the response to the challenge string andchecks 530 the response. Checking the response includes determiningwhether the signature on the response corresponds to the public keyincluded in the response. Checking 530 the response may also includeretrieving the challenge issued to authenticate the network connectionand determining whether the received response matches the expectedresponse to the retrieved challenge. Checking the response against thechallenge string prevents a replay attack where a malicious user sends aresponse generated by the remote program in response to a previouschallenge string.

Checking 530 the response further includes determining whether thepublic key included in the response is valid by determining whetherthere is a chain of trust between the public key and the approved publickey. For example, a chain of trust exists when the public key in theresponse is an approved public key or has been signed by an approvedpublic key. Verifying the chain of trust between the public key and anapproved public key may be a recursive process. The message router 240identifies the parent public key used to sign the public key included inthe response and determines whether there is a chain of trust betweenthe parent public key and an approved public key. Once a parent publickey is identified that is an approved public key, the chain of trust isvalidated. If the recursive process identifies a parent public key thatis not an approved public key and that has not been signed by any otherpublic key, then the chain of trust is invalid.

In response to determining that the response matches the challengestring, the message router 240 determines that the identity of theremote program is authenticated, and the message router 240 allows theclient application 205 to begin sending and receiving messages throughnetwork connection 217. In response to determining that the responsedoes not match the challenge string, the message router 240 determinesthat the remote program does not have a valid identity, and the messagerouter 240 terminates the corresponding network connection 217 throughan instruction to the connection manager 230.

Authentication Transfer

A messaging environment refers to a plurality of messaging server nodesconnected to each other. The messaging server nodes in a given messagingenvironment can only communicate with other messaging server nodes inthe same messaging environment. However, some client applications 205may connect to and interact with multiple segregated messagingenvironments (e.g., messaging environments in different organizations).

To this end, authentication transfer refers at a high level to a clientapplication 205 leveraging an authentication previously done with amessaging server 120A in messaging environment A as a credential toauthenticate to a new messaging server 120B in a new messagingenvironment B. When connecting to the new messaging server 120B, theclient application 205 receives a challenge string from the newmessaging server 120B as part of receiving a unique challenge string forcertificate-based authentication (e.g., step 515 in FIG. 5). Uponreceipt of this challenge string, the client application 205 generatesan authentication transfer ticket request and sends it to the messagingserver 120A. The authentication transfer ticket request contains thisnew challenge string. The message router 240 on the messaging server120A signs the authentication transfer ticket with its own private keyand returns an authentication transfer ticket response to the clientapplication 205. The client application 205 in turn submits a loginrequest based on the authentication transfer ticket response to the newmessaging server 120B, which decrypts the signature, verifies thevalidity of the user name and original network, and acknowledges to theclient application 205 that this constitutes a successfulauthentication. Thus, authentication transfer obviates a user entering auser name and password when switching between messaging servers indifferent messaging environments.

FIG. 6 is an interaction diagram illustrating in detail an exampleprocess of transferring authentication for a client device betweenmessaging servers, in accordance with an embodiment. A clientapplication 205 of client device 110 is maintaining 600 an initialnetwork connection 217 with messaging server 120A. The initial networkconnection 217 has been authenticated, such as through certificate-basedauthentication. The client device 110A initiates 605 a networkconnection 215 with messaging server 120B, which is remote relative tomessaging server 120A. For example, messaging server 120A is affiliatedwith organization A, messaging server 120B is affiliated with to adifferent organization B, and the client application 205 that wasalready connected and authenticated to messaging server 120A isattempting to communicate with organization B via messaging server 120B.This mechanism allows client application 205 to authenticate tomessaging server 120B without prompting the user for credentials formessaging server 120B's organization (organization B in this example).This mechanism is not limited to cross-organization communication. Aclient application 205 may also use the authentication transfermechanism to connect to another messaging server 120 in the sameorganization as messaging server 120A without providing user name andpassword credentials.

The messaging server 120B sends 610 a greeting message including achallenge string. For example, the greeting message includes a 24-bytechallenge string and a messaging system version number, and the greetingmessage is delivered through a secure socket connection. The clientdevice 110 receives the greeting message and sends 615 the messagingserver 120B a response to the greeting message. The messaging server120B begins waiting for a login request after receiving the response tothe greeting message.

The client device 110 generates and sends 620 an authentication transferticket request (“authentication request”) to the messaging server 120A,which has already authenticated the identity of the client application205. The authentication request is message with a header indicating thatthe message is an authentication request. The header includes a sourceidentifier corresponding to the authentication request. The body of theauthentication request includes the challenge string sent by themessaging server 120B. The messaging server 120A generates anauthentication transfer ticket response (“authentication response”)including a signed authentication credential. The messaging server 120Asigns 625 the authentication credential using a private key. Theauthentication response is a message having a header indicating that themessage is an authentication response. The header includes the sourceidentifier from the authentication request, and the body of theauthentication response includes the signed authentication credential(e.g., the challenge string encrypted using a signature of the messagingserver 120A). The messaging server 120A sends 630 the authenticationresponse to the client device 110.

The client device 110 generates and sends 635 a login request to themessaging server 120B. The login request is a message containing a username of the client application 205, messaging environment metadata, andthe signed authentication credential from the authentication response.Messaging environment metadata describes the organization correspondingto a messaging environment (e.g., a messaging system code for theorganization, an abbreviation of the organization) as well as othercharacteristics of the messaging environment. The messaging server 120Bchecks 640 the login request by: (1) decrypting the challenge string andconfirming the challenge string matches the challenge string sent in thegreeting message; (2) confirming that the authenticated challenge stringhas a format consistent with an authentication transfer ticket response;(3) checking the signature on the authenticated challenge string isvalid;

(4) verifying that the signer is a messaging server, such as 120A, thatis authorized to issue authentication transfer responses; and (5)checking that the client application 205 (and/or client device 110) isauthorized to generate authentication transfer requests for thedestination client application 205 associated with the messaging server120B. If the messaging server 120B determines that the login request isinvalid (because any of steps (1) through (5) are invalid), themessaging server 120B closes the network connection 215 with the clientdevice 110.

If the login request passes the checks, the messaging server 120Brequests verification of the user name and messaging environmentmetadata included in the login request by generating and sending 645 auser verification request to an authentication server 601. Theauthentication server 601 maintains a registry of valid user names andassociated messaging environment metadata to provide a further check oninformation contained in the login request. For example, theauthentication server queries LDAP on behalf of messaging server 120B toverify the information in the login request. LDAP contains metadataabout user accounts, such as user names, passwords, and associatedmessaging environment metadata (e.g., organization abbreviations). Theuser verification request indicates that it is a user verificationrequest and includes the user name and abbreviation of the clientapplication's organization from the login request. The user verificationrequest may further include a header indicating that the userverification request is a semaphore type message. The header alsoincludes the source identifier of the client application 205. Theauthentication server 601 verifies 650 the information contained in theuser verification request to ensure that (1) the user name is valid and(2) the messaging environment metadata matches the user name.

In response to successfully verifying 650 the information included inthe user verification request, the authentication server 601 generatesand sends 655 a user verification response to the messaging server 120Band the client device 110. The user verification response is a messageincluding a header indicating the message is a user verificationresponse. The header of the user verification response includes thesource identifier and a code corresponding to the organization of theclient application 205.

In response to receiving the user verification response indicatingverification of the user name, the messaging server 120B accepts thenetwork connection 215 with the client device 110. If the userverification response indicates that the user name is invalid, or if theother information in the user verification request does not match theuser name, the messaging server 120B closes the network connection 215.

Authenticating Component Program Identity

FIG. 7 is an interaction diagram illustrating an example process ofauthenticating identity of a component program, in accordance with anembodiment. In the illustrated example, the messaging server 120establishes a chain of trust between the dispatcher 220 and anotherprogram component (e.g., a message router 240, a connection manager230). By establishing the chain of trust between the program components,the messaging server 120 may send secure information between the programcomponents through an IPC socket connection (e.g., 225 or 227).

The dispatcher 220 connects 705 to shared memory contained in statestore 250. The dispatcher 220 may connect 705 to the shared memory inresponse to the messaging server 120 powering on or restarting, forexample. The messaging server 120 initializes the dispatcher 220 as aroot user. A root user refers to an identity having permissions notavailable to other component programs of the messaging server 120. As aroot user, the dispatcher 220 may instantiate another component program,instantiate an IPC connection between component programs, temporarilychange its own identity to another user having fewer authorizations, andread and write to shared memory accessible only by a root user. Thedispatcher 220 determines whether the state store 250 contains sharedmemory for the dispatcher 220. If the state store 250 contains adispatcher shared memory, the dispatcher 220 reconnects to thedispatcher shared memory. If the state store 250 does not contain thedispatcher shared memory, the dispatcher 220 allocates the dispatchershared memory and connects to it. As part of allocating the dispatchershared memory, the dispatcher 220 sets the dispatcher shared memory toallow read and write access only to component programs having a rootuser identity.

The dispatcher 220 begins listening on an IPC server socket connection225 or 227 used by the connection manager 230 and the message router 240to connect to the dispatcher 220.

The dispatcher 220 determines whether the messaging server 120 isexecuting a message router 240 and a connection manager 230. If themessaging server 120 is executing the message router 240 and theconnection manager 230, the process continues to step 720. If one orboth of these components is not running on the messaging server 120, thedispatcher 220 instantiates 715 whichever of them is not running. To dothis, the dispatcher 220 changes its identity to a reduced or minimalpermissions user identity, such as one used to create 710 the IPC socketconnections 225 and 227. Using the user identity, the dispatcher 220instantiates 715 the message router 240 and/or the connections manager230. The dispatcher 220 stores a process identifier and the start timeof the message router 240 and/or the connection manager 230, as well asthe corresponding user identity, in the dispatcher shared memory(reverting to the root user identity first if necessary). These storeditems of information may be referred to as “instantiation information”for convenience, and may be used to verify the identity of the processwhen it requests private keys and other secure information. Thedispatcher 220 then reverts its identify to the root user identity.

The message router 240 and connection manager 230 open connections 225and 227, respectively with to the IPC server socket that the dispatcher220 opened previously.

As a final set of steps in establishing a secure connection to thedispatcher 220, the message router 240 or the connection manager 230requests 725 the private key over 225 and 227, respectively. In responseto the request, the dispatcher 220 verifies 730 the identity of themessage router 240 or connection manager 230. To do this, the dispatcher220, as the root user identity, queries the operating system of themessaging server 120 for the user identity, the process identifier,and/or start time of the message router 240 or connection manager 230making the request. The dispatcher 220, as the root user identity, alsoqueries the dispatcher shared memory for the process identifier, starttime, and/or corresponding user identifier associated with the request.The dispatcher 220 compares the process identifier, start time, and/orcorresponding user identity accessed from the dispatcher shared memorywith those of the requesting message router 240 or connection manager230. If all of the process identifier, start time, and/or correspondinguser identity match between the dispatcher shared memory and requestingcomponent, the dispatcher 220 sends 735 the private key (or otherrequested secure information) to the requesting message router 240 orconnection manager 230 through the corresponding IPC socket 225 or 227.

If any of the process identifier, start time, and/or corresponding useridentifier do not match, the dispatcher 220 closes the IPC socket 225 or227 and/or the network connection 217 corresponding to the request.

The dispatcher 220 obtains the private key from a client device 110 thathas initiated an authenticated connection, as described in conjunctionwith FIG. 3. To obtain the private key, the dispatcher 220 accesses anencrypted version of the private key using a public file system mount.For example, the file system mount is an NFS (Network File System)mount. The dispatcher 220 decrypts the encrypted private key and storesthe encrypted private key in process memory of the dispatcher.Alternatively, the dispatcher 220 stores the encrypted private key indispatcher shared memory or other memory accessible to the dispatcher220 and not accessible to the message router 240 and connection managers230. To decrypt the private key, the dispatcher 220 may, for example,use symmetric key decryption (e.g., Advanced Encryption Standard (AES)),assuming the key was encrypted accordingly. To do this, the dispatcher220 may change its identity to a key access user identity having accessto the symmetric key, load the symmetric key from a private file systemmount accessible only to the key access user identity, and decrypt theprivate key using the loaded symmetric key. The dispatcher 220 thenreverts its identify to the root user identity. The dispatcher 220 mayaccess the encrypted private key during a TLS (transport layer security)session or prior to establishing a TLS session. To establish a TLSsession, the message router 240 instructs the connection manager 230 toestablish the TLS session after confirming the network connection 217(e.g., step 370 in FIG. 3). After establishing the TLS session, theconnection manager 230 may use the decrypted private key to upgrade thenetwork connection 217 to an encrypted TLS connection.

The dispatcher 220 also secures the IPC messages queues 235 betweenconnection managers 230 and the message router 240. This allowsconnection managers 230 and the message router 240 to trust each other.The dispatcher 220 determines whether the message queues 235 exist onthe messaging server 120. If the corresponding message queues 235 exist,the dispatcher continues to step 715. If the corresponding messagequeues 235 do not exist, the dispatcher 220 creates message queues 235(e.g., immediately before, immediately after, or concurrently with step710). To do this, the dispatcher 220 changes its identity to a reducedor minimal permissions user identity, which is a preconfigured accountused permanently by the message router 240 and the connection managers230, and temporarily by the dispatcher 220. Using the minimalpermissions user identity, the dispatcher 220 then creates the messagequeues 235 and sets permission for the message queues 235 so that only auser with those same user identity permissions user may connect. Thedispatcher 220 then reverts its identify to the root user identity.

Additional Configuration Information

In the client device 110 and messaging system 120, the program code andmodules implementing the functionality described herein are not nativecomponents of underlying machine or system, and thus extend theoperations and functionality thereof beyond their generic functions andcapabilities. The client device 110 includes a client application 205,and the messaging system 120 includes a dispatcher 220, a connectionmanager 230, a message router 240, a state store 250. Those of skill inthe art will appreciate that these databases, information, datastructures, program code, and modules are not components of a genericcomputer, and that the client device 110 messaging system 120 maycontain other databases, program code, or modules that are notexplicitly mentioned here. Additionally, the operations listed here arenecessarily performed at such a frequency and over such a large set ofdata that they must be performed by a computer in order to be performedin a commercially useful amount of time, and thus cannot be performed inany useful embodiment by mental steps in the human mind.

Some portions of the above description describe the embodiments in termsof algorithmic processes or operations. These algorithmic descriptionsand representations are commonly used by those skilled in the dataprocessing arts to convey the substance of their work effectively toothers skilled in the art. These operations, while describedfunctionally, computationally, or logically, are understood to beimplemented by computer programs comprising instructions for executionby a processor or equivalent electrical circuits, microcode, or thelike. Furthermore, it has also proven convenient at times, to refer tothese arrangements of functional operations as modules, without loss ofgenerality. The described operations and their associated modules may beembodied in software, firmware, hardware, or any combinations thereof.

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and B is false (or not present), A is false (or notpresent) and B is true (or present), and both A and B is true (orpresent).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the disclosure. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for authenticating network connections andcomponent program identities in a messaging system. Thus, whileparticular embodiments and applications have been illustrated anddescribed, it is to be understood that the described subject matter isnot limited to the precise construction and components disclosed hereinand that various modifications, changes and variations which will beapparent to those skilled in the art may be made in the arrangement,operation and details of the method and apparatus disclosed herein.

What is claimed is:
 1. A method of authenticating network connectionsbetween a remote program and a messaging system comprising componentprograms including at least one from a group consisting of a dispatcher,a message router, and a connection manager, the method comprising:receiving, at a port associated with the connection manager, a networkconnection transferred from the dispatcher; sending the client device achallenge string containing data unique to the network connection;receiving a challenge string response from the remote program, thechallenge string response including a signature on the challenge stringfrom with a private key paired with an approved public key; verifyingwhether the received challenge string response is valid for the networkconnection; and responsive to determining that the received challengestring response is valid, processing messages sent through the networkconnection.
 2. The method of claim 1, wherein the remote program is oneof a client application executed by a client device and a componentprogram executed by another messaging server different from a messagingserver executing the dispatcher.
 3. The method of claim 1, wherein theprivate key is generated using a root private key paired with theapproved public key, the root private key is accessible to the remoteprogram, and the approved public key is accessible to the remote programand the dispatcher.
 4. The method of claim 1, wherein sending thechallenge string comprises storing the challenge string in associationwith the network connection, wherein the received challenge stringresponse includes a public key, and wherein verifying whether thereceived challenge string response is valid comprises: determiningwhether the challenge string response corresponds to the storedchallenge string associated with the network connection; determiningwhether there is a valid chain of trust between the public key and theapproved public key; and determining whether the signature on thereceived challenge string response corresponds to the public keyincluded in the received challenge string response.
 5. The method ofclaim 1, further comprising instructing the connection manager to closethe network connection responsive to determining that the receivedchallenge string response is invalid.